The basics

• I validated my changes

The details

Proposed Changes

This PR backports the support for moving blocks, workspace comments, and bubbles using the keyboard from the blockly-keyboard-experimentation repo to core Blockly. These interactions have been proved out through user testing, and are an important foundational aspect of making Blockly more accessible. Toward this end, the following changes have been made:

• The IDragger, IDraggable and IDragStrategy interfaces have been revised to put less of an emphasis on mouse events and clean up some other issues that using them in practice has revealed. See the Breaking Changes section below for more details.
• A new KeyboardMover class has been introduced. An instance of this class is owned by WorkspaceSvg, and is used to coordinate keyboard-driven movement between keyboard shortcuts and the dragging system.
• Keyboard shortcuts for entering and exiting move mode and moving in each cardinal direction have been introduced. These are mapped to M (start move), arrow keys (move in the corresponding direction), Enter (commit an in-progress move) and Escape (revert an in-progress move).
  • For blocks in particular, keyboard-driven moves move them between available connection locations by default. Blocks may be freely moved around the workspace by pressing Option (Apple platforms) or Control (Windows, Linux, ChromeOS, etc) in conjunction with the arrow keys.

Future Work

At present, it is not possible to insert blocks from the flyout using the keyboard. This is now feasible, but in the interest of avoiding scope creep and preventing this PR from becoming even larger I will include it in a followup PR.

Additionally, the remaining functionality from the blockly-keyboard-experimentation repo still needs to be backported to core.

Test Coverage

Tests have been added that exercise each kind of built-in movable entity (blocks, workspace comments, and bubbles). Additionally, the test suite for constrained movement of blocks from the blockly-keyboard-experimentation repo has been backported.

Breaking Changes

If your application has custom code that implements the IDragger, IDraggable, or IDragStrategy interfaces, you may need to make some changes. Specifically:

• IDragStrategy.startDrag() and IDraggable.startDrag() need to return an IDraggable that the rest of the drag process will act on. Typically, IDraggables should just return themselves. In cases where you want a drag to act on a different element than the one the drag started on, you can return the object you actually want the drag to act on.
• All drag-related methods that previously accepted a PointerEvent now need to handle receiving a PointerEvent | KeyboardEvent. In keyboard-driven drags, this will be a KeyboardEvent.
• Classes that implement IDragger now need to implement IDragger.onDragRevert(). This method differs from onDragEnd() in that it is invoked when a drag is cancelled or reverted by the user; generally, the item being dragged should be moved back to its starting position. If a drag is reverted, onDragEnd() will still be invoked after onDragRevert() has been called, so common cleanup can be reliably handled there.
• The event arguments to methods in IDragger have been made optional, consistent with IDraggable and IDragStrategy. Your code should not rely on them being present, although they typically will be for both mouse- and keyboard-driven drags.